
Serial No.: 09/604,428 
Examiner: Vu, Thong H 
Art Unit: 2142 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Applicant: Michelle Baker 
Serial No.: 09/604,428 
Filed: 27 JUN 2000 



Group Art Unit: 2142 
Examiner: Vu, Thong H 
Attorney Docket: BAK-007 



Title: Electronic Mail Software with modular integrated authoring/reading software 
components including methods and apparatus for controlling the interactivity between 
mail authors and recipients 



I hereby certify that this correspondence is being deposited on this day with 
the United States Postal Service as first class mail in an envelope addressed 
to: Commissioner for Patents, Alexandria, VA 22313-1450. 

David P. Gordon n **» " 



Honorable Commissioner for Patents 
Alexandria, VA 22313 

Sir: 



RECEIVED 

JAN 1 5 2004 

Technology Center 2100 



PETITION FOR THREE MONTH EXTENSION OF TIME TO REPLY 

The applicant hereby petitions the Commissioner of Patents and Trademarks for a 
three month extension of time to reply to an Office Action (paper #5) dated July 9, 2003. 
With the extension of time, the time for reply is extended from October 9, 2003 to 
January 9, 2004 making this reply timely in nature. The $475 small entity fee for the 
three month extension is enclosed herewith. 



01/14/2004 RHEBRAHT 00000160 09604428 

01 FC:2253 475.00 OP 



1/21 




AMENDMENT TO THE SPECIFICATION 

Page 1, paragraph 1, replace with: 

This application is a continuation-in-part of application serial number 09/209,162 
filed December 10, 1998, and serial number 09/604,426 filed June 27, 2000 the complete 
disclostires of which are hereby incorporated by reference herein. 

In the Abstract, replace with: 

Electronic mail software includes a main email component and a number of 
installable components which communicate bidirectionally with the email component 
through an application programming interface (API). The installable components include 
authoring/reading components and a mailbox browser/editor component. The main email 
component provides an underlying graphical user interface (GUI) for functions directly 
associated with the storage and transfer of electronic mail messages and also handles all 
data bundling and unbundling that may be required to transform a message created by an 
authoring component into a fully MIME compliant message. The main email component 
includes an API for the attachment of installable components. The authoring/reading 
components each provide functionality particular to the type of document the component 
is designed to create/display. Some modular components, or messages created by them, 
have assigned "roles" whereby senders and recipients of certain email documents are 
provided different kinds of access to the documents. 



2 



STATEMENT OF THE CLAIMS 
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1. (original) An electronic mail client, comprising: 

a) a mail handling component for sending and receiving electronic mail; and 

b) an authoring/reading component for creating electronic mail messages and for 
reading electronic mail messages, 

said authoring/reading component having at least two modes of authoring, 
said modes being selectable by said authoring/reading component when creating 
an electronic mail message, wherein 

each mode causes the electronic mail message to be displayed in a different 
mannerWen read by the authoring/reading component. ? *-y L*o J 



2. (original) An electronic mail client according to claim 1, wherein: 

said two modes are selected from the group consisting of customer and vendor, 
teacher and student, auctioneer and bidder, and doctor and patient. 

3. (currently amended) An electronic mail client according to claim 1, wherein: 

the mode of a message is encoded in the message and determined by the 
authoring/reading component when the message is cr e at e d read . 



4. (original) An electronic mail client according to claim 3, wherein: 
the mode of a message is encoded as a MIME-type. 
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5. (original) An electronic mail client according to claim 1, wherein: 

a message created in a first of said two modes allows a recipient of the message to 
use a first set of tools to respond to the message, and 

a message created in a second of said two modes allows a recipient of the 
message to use a second set of tools to respond to the message, said first set of tools and 
said second set of tools being different from each other. 

6. (original) An electronic mail client according to claim 1, wherein: 

a message created in a first of said two modes allows a recipient of the message to 
see all of the information contained in the message, and 

a message created in a second of said two modes allows a recipient of the 
message to see a only subset of the information contained in the message. 

7. (original) An electronic mail client according to claim 1, wherein: 

a message created in a first of said two modes allows a recipient of the message to 
see the information contained in the message organized in the same way it appeared 
during creation of the message, and 

a message created in a second of said two modes prevents a recipient of the 
message from seeing the information contained in the message organized in the same 
way it appeared during creation of the message, and only allows the recipient to see the 
information organized in a different way. 
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^(original) An electronic mail system, comprising: 

a) a first electronic mail client having a first authoring/reading component for creating 
and reading electronic mail messages; and 

b) a second electronic mail client having a second authoring/reading component for 
creating and reading electronic mail messages, wherein 

said first authoring/reading component creates messages in a first mode and said 
second authoring/reading component reads messages in a second mode, each mode 
causing messages to be displayed in a different manner. 

9. (original) An electronic mail system according to claim 8, wherein: 

said first and second modes are selected from the group consisting of customer 
and vendor, teacher and student, auctioneer and bidder, and doctor and patient. 

10. (original) An electronic mail system according to claim 8, wherein: 

the mode of displaying a message is encoded in the message by the first 
authoring/reading component and determined by the second authoring/reading 
component when the message is read. 

11. (currently amended) An electronic mail system according to claim 8, wherein: 

a message displayed in said first mode allows a viewer of the message to use a 
first set of tools to creat e respond to the message, and 
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a message displayed in said mode allows a view of the message to use a second 
set of tools to respond to the message, said first set of tools and said second set of tools 
being different from each other. 

12. (original) An electronic mail system according to claim 8, wherein: 

a message viewed in said first mode allows the viewer of the message to see all of 
the information contained in the message, and 

a message created in said second mode allows the viewer of the message to see 
only a subset of the information contained in the message. 

13. (original) An electronic mail system according to claim 8, wherein: 

a message viewed in said first mode allows a viewer of the message to see the 
information contained in the message organized one way, and 

a message viewed in said second mode only allows the recipient to see the 
information organized in a second way different from said first way. 

(^(original) An electronic mail client, comprising: 

a) a plurality of authoring/reading components for creating and viewing representations 
of information; 

b) encoding means for automatically encoding representations created with said 
authoring/reading components into an Internet compatible email message; and 

c) decoding means for automatically decoding said representations encoded by said 
encoding means, wherein 
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at least one of said authoring/reading components is responsive to a role mode 
encoded in an email message whereby said role mode determines how information in said 
email message will be displayed. 

15. (original) An electronic mail client according to claim 14, wherein: 

said role modes are selected from the group consisting of customer and vendor, 
teacher and student, auctioneer and bidder, and doctor and patient. 

16. (original) An electronic mail client according to claim 14, wherein: 

a message encoded with a first role mode allows a recipient of the message to use 
a first set of tools to respond to the message, and 

a message encoded with a second role mode allows a recipient of the message to 
use a second set of tools to respond to the message, said first set of tools and said second 
set of tools being different from each other. 

17. (original) An electronic mail client according to claim 14, wherein: 

a message encoded with a first role mode allows a recipient of the message to see 
all of the information contained in the message, and 

a message encoded with a second role mode allows a recipient of the message to 
see a only subset of the information contained in the message. 



18. (original) An electronic mail client according to claim 14, wherein: 

a message encoded with a first role mode allows a recipient of the message to see 
the information contained in the message organized in the same way it appeared during 
creation of the message, and 

a message encoded with a second role mode prevents a recipient of the message 
from seeing the information contained in the message organized in the same way it 
appeared during creation of the message, and only allows the recipient to see the 
information organized in a different way. 

19. (original) An electronic mail client, comprising: 

a) a main email component for sending and receiving messages; and 

b) a plurality of installable authoring/reading components for creating and reading 
messages, wherein 

said main email component communicates with said authoring/reading 
components through a bidirectional application programming interface. 

20. (original) An electronic mail client according to claim 19, wherein: 

said application programming interface provides at least one function call to said 
main email client by an authoring/reading component selected from the group consisting 
of get message, send message, save message, pass message, get registered users, enable 
button, disable button, and kill component. 
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21. (original) An electronic mail client according to claim 20, wherein: 

said application programming interface provides at least one function call to an 
authoring/reading component by said main email client selected from the group 
consisting of close window, get component info, initialize window, send message, open 
message, reply message, clear message, print message. 

22. (original) A method of corresponding by electronic mail, comprising: 

a) creating a representation of information; 

b) encoding the representation into an Internet-compatible email message; 

c) sending the email message to an email client; and 

d) decoding the email message at the email client, wherein 

the email client is responsive to a role mode encoded in the email message 
whereby the role mode determines how information in said email message will be 
displayed. 

23. (original) A method according to claim 22, wherein: 

the role mode is selected from the group consisting of customer and vendor, 
teacher and student, auctioneer and bidder, and doctor and patient. 

24. (original) A method according to claim 22, wherein: 

the role mode of a message is encoded as a MIME-type. 
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25. (original) A method according to claim 22, wherein: 

the role mode determines what tools may be used by the email client to view the 
representation of information. 

26. (original) A method according to claim 25, wherein: 

the role mode determines what tools may be used by the email client to respond to 
the message. 

27. (original) A method according to claim 22, wherein: 

the role mode determines how much of the representation of information can be 
viewed by the email client. 
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REMARKS 



The Examiner has objected to the Abstract for being too many words. A new 
Abstract having fewer than 150 words has been provided. 

The Examiner has also objected to the blank reference to one of the parent 
applications. This reference has been corrected. 

Claims 1-27 are pending in the application. Claims 1-13 stand rejected under 35 
U.S.C. § 103(a) as obvious over Marcus in view of Kumomura. Although not included in 
the statement of the rejection, the Examiner apparently includes the Holleran reference in 
the rejection. The Examiner claims that Marcus teaches all of claim 1 except for the last 
clause. With regard to the last clause of claim 1, the Examiner states that it is taught by 
Holleran and Kumomura. As for the incentive to combine features of the secondary 
references with the primary references, the Examiner concludes that the incentive would 
be to "provide a simple, quick and efficient method to process email on a network." 

The Examiner's rejection is respectfully traversed for the following reasons. 
First, Marcus does not teach an electronic mail client which include an authoring/reading 
component having two modes of authoring as claimed in claim 1 . Second, neither 
Holleran nor Kumomura suggest authoring modes which cause an electronic mail 
message to be displayed in a different manner when read. Third, the Examiner's stated 
incentive to combine the references is invented and inappropriate. 
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Turning to the first reason, Marcus discloses a system and method for providing a 
proxy identifier in an on-line directory which is a method to protect the privacy of a 
person's email address. The relevant portions of the Marcus reference cited by the 
Examiner do not describe an authoring component which has two modes of authoring. 
Column 4, lines 6-18 of Marcus describes a proxy email address which has two selectable 
portions. This is clearly not the same as an authoring component which has two modes 
of authoring. Column 4, lines 32-52 of Marcus describes different embodiments of the 
processing system which creates an email message using information previously input. 
In each embodiment, the email address of the sender appears in a different way: the 
directory service with the sender's name, the user's inputted email address, or the 
directory service without the sender's name. This is still not an authoring component 
which has two selectable modes of authoring. There is no suggestion in Marcus that the 
processing system operate in more than one mode. The discussion of separate 
embodiments, each operating in a different mode is not a suggestion that a single 
embodiment can operate in more than one mode or that modes are selectable. Thus, it is 
respectfully submitted that the Examiner has not read Marcus correctly. 

As for the second reason, the last clause of claim 1 is neither taught nor suggested 
by either Holleran or Komumora. Holleran discloses a method and apparatus for 
depicting an electronic mail address in different formats. The final clause of claim 1 of 
the present application relates to the display of an electronic mail message , not the 
address. The cited portion of Holleran (col. 7, lines 25-44) discusses the use of templates 
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to format mail addresses in different ways. Thus, there is no suggestion in Holleran to 
display email messages in different ways depending on how they were authored. 
Kumomura discloses a method of approving electronic mail Received mail which needs 
to be approved is displayed with a blinking approval seal. The cited portions of 
Kumomura do not suggest displaying electronic mail messages in different ways 
depending on the mode in which it was authored by an authoring tool having selectable 
authoring modes. Col. 6, lines 5-16 of Kumomura cited by the Examiner discusses 
displaying the approval seal in solid lines or dotted lines depending on the status of the 
approval process. The approval seal is not part of the electronic mail message. Col 7, 
lines 44-67 of Kumomura cited by the Examiner is a portion of claim 1 of the Kumomura 
patent. It describes displaying approval imprints in different ways. The approval 
imprints are not part of the electronic mail message and were not authored by the sender 
of the message. Col. 8, lines 18-26 of Kumomura cited by the Examiner are claims 4-6 
of the Kumomura patent. These claims discuss displaying the approval imprint in solid 
lines, dotted lines, blinking, and dimmed. The approval imprints are not part of the 
electronic mail message and were not authored by the sender of the message. Col. 9, 
lines 5-12 of Kumomura cited by the Examiner is part of claim 16 of the Kumomura 
patent. These lines discuss displaying a list of electronic mail messages by category and 
displaying a piece of electronic mail when it is selected from the list. This does not teach 
or suggest displaying electronic mail messages in different ways depending on the mode 
in which it was authored by an authoring tool having selectable authoring modes. 
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The third reason for traversing the Examiner's rejection is that the stated incentive 
to combine the references is improper and inappropriate. It is improper because the 
incentive cannot be found in the prior art; it is simply stated by the Examiner. It is also 
improper because it is the facile "to make it better" incentive which is the hallmark of 
hindsight. How was it known that the combination would make email processing better? 
It is inappropriate because the aim of the present invention is not to "provide a simple, 
quick and efficient method to process email on a network" as stated by the Examiner. 
The aim of the present invention is to control access to the content of an email message 
depending on the reader's "role". This is made clear throughout the specification as well 
as in the dependent claims. 

The Examiner rejects independent claim 8 on the grounds that it is similar to 
claim 1. Thus, the remarks made above regarding claim 1 apply to this rejection as well. 
Claim 8 is actually quite different from claim 1 and the Examiner's rejection of it is 
incomplete because it does not address the limitations of claim 8 which are different from 
the limitations of claim 1. Thus, should the Examiner decide to continue this rejection, a 
proper analysis of the claim is respectfully requested. 

Dependent claims 2 and 9 specify that the authoring modes are "selected from the 
group consisting of customer and vendor, teacher and student, auctioneer and bidder, and 
doctor and patient." The Examiner states that this is disclosed by Marcus at col. 7, lines 
21-50. This cited portion of Marcus constitutes claims 21-26 of the Marcus patent and 
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discusses displaying a list of records. It is not seen how this teaches or suggests the 
subject matter of claims 2 and 9. 

Dependent claims 3 and 10 include the limitation that the mode of a message is 
encoded in the message by the authoring component and determined by the reading 
component (claim 10) when the message is read. The Examiner states that this is taught 
by Marcus at col. 5, lines 42-58 and col. 6, lines 3-15. These cited portions are claims 1 
and 3 of the Marcus patent. Claim 1 makes no mention of encoding a message. Claim 3 
refers to selectable proxy addresses so that an email may be sent without knowing the 
recipient's email address. Although this might be viewed, in hindsight with knowledge 
of the present invention, as encoding the recipient's address in a selected mode, it is not 
encoding the mode of displaying the message . 

With regard to claim 4, although MIME types are known, it is not known to use 
them in the manner claimed and the Examiner has not pointed out where it is taught or 
suggested in the prior art. 

Dependent claims 5 and 1 1 state that the recipient of the email message can reply 
to it using different tools depending on the mode in which the message was authored. 
The Examiner states that this is taught by Kumomura at col. 6, lines 5-16, col. 7, lines 44- 
67, col. 8, lines 16-26, and col. 9, lines 5-12. Col. 6, lines 5-16 discuss displaying the 
approval seal as solid, blinking or dotted. This has nothing to do with determining the 
way a recipient can respond by the way a message is encoded. Col. 7, lines 44-67 is part 
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of claim 1 of the Kumomura patent. It does not deal in any way with replying to an email 
message. In claim 1 of the Kumomura patent, an email is approved and sent to a next 
approval person. Col. 8, lines 16-26 are claims 3-6 of the Kumomura patent. They deal 
with how the approval imprint is displayed. They do not deal in any way with replying to 
an email message. Col. 9, lines 5-12 are part of claim 16 of the Kumomura patent. These 
lines deal with displaying a list of email messages. They do not relate to replying to an 
email message. 

Dependent claims 6 and 12 state that depending on the mode in which the 
message was authored, the recipient may see all or only part of the message. In rejecting 
these claims, the Examiner refers to the same portions of the Kumomura patent as in the 
rejection of claims 5 and 11. Those portions of the Kumomura patent are discussed 
above and clearly have nothing to do with the content of claims 6 and 12. The Examiner 
is reminded that the approval seal is not part of the email message. 

Dependent claims 7 and 13 state that the organization of the information in the 
email message as seen by the recipient is dependent on the mode of authoring. In 
rejecting these claims, the Examiner refers to the same portions of the Kumomura patent 
as in the rejection of claims 5 and 11. Those portions of the Kumomura patent are 
discussed above and clearly have nothing to do with the content of claims 7 and 13. The 
Examiner is reminded that the approval seal is not part of the email message. 
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Claims 14-18 and 22-27 stand rejected under 35 U.S.C. § 103(a) as obvious over 
Marcus in view of Kato. However, in the discussion of the rejection, the Examiner does 
not refer to Kato, but instead refers to the combination of Marcus with Eryq. The 
Examiner states that Marcus teaches clause a) of claim 14 but not clauses b) or c). 
Clauses b), c) and the wherein clause are, according to the Examiner, taught by Eryq. 
The stated incentive for combining the references is to "provide a security [sic] and 
efficient process for using email on a network." The Examiner does not cite where this 
incentive can be found in the prior art. 

Clause a) of claim 14 requires "a plurality of authoring/reading components for 
creating and viewing representations of information". The Examiner states that this is 
taught by Marcus at col. 4, lines 32-52. This portion of Marcus discusses the different 
embodiments of the processing system. The Applicant has addressed this portion of 
Marcus above. This is not a teaching of multiple authoring/reading components. The 
teaching of different embodiments is not a teaching that more than one embodiment 
should be present together. 

Clauses b) and c) of claim 14 relate to encoding and decoding means for making 
the messages Internet compatible. The final clause of claim 14 states that "at least one of 
said authoring/reading components is responsive to a role mode encoded in an email 
message whereby said role mode determines how information in said email message will 
be displayed." The Examiner states that Eryq teaches all of this and cites pages 1-12 (i.e. 
all) of Eryq. 
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The Eryq reference is a document entitled "MIME-tools-modules for parsing (and 
creating!) MIME entities." It discusses the standard techniques for encoding MIME 
types in email. It does not mention the use of a role mode encoded in an email message 
with the role mode determining how information in the message will be displayed. Eryq 
describes how a GIF file can be attached to an email message but does not describe or 
suggest that the GIF file can be "role mode encoded" to determine how it is to be 
displayed. Presumably it is always displayed as an image. In the claimed invention, the 
role mode encoding could determine that the GIF file be displayed as a binary 
representation of an image or as a hexadecimal representation of an image or as the 
image. Eryq also describes that email messages can be encoded in different ways, 7bit, 
8bit, binary, quoted-printable, or base64. These encodings do not, however, determine 
how the information is to be displayed, only how it is to be transmitted. Thus, even if 
Marcus and Eryq were combined with hindsight, one could not achieve the invention 
claimed in claim 14. 

Independent claim 22 is a method claim which is similar to claim 14. The 
Examiner rejects this claim on the same grounds as claim 14 and thus, the remarks made 
above regarding claim 14 apply to this rejection as well. 

Dependent claims 15-18 are rejected on the grounds that they contain similar 
limitations as claims 2, and 5-7. Therefore, the Applicant's comments regarding claims 2 
and 5-7 apply to this rejection as well. 
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Dependent claim 23 states that "the role mode is selected from the group 
consisting of customer and vendor, teacher and student, auctioneer and bidder, and doctor 
and patient." The Examiner states that this is disclosed by "Marcus-Eryq", but does not 
cite any portion of either reference. It is respectfully submitted that neither reference 
suggests the limitations of claim 23. 

Claim 24 requires that the role mode is encoded as a MIME type. Although the 
prior art teaches MIME types, none suggests the use of a role mode as claimed herein and 
as discussed above. 

Claim 25 requires that the role mode determines what tools may be used to view 
the information. In rejecting this claim, the Examiner cites the entire 12 pages of the 
Eryq reference. As discussed above, none of the cited art suggests the use of role modes. 

Claim 26 requires that the role mode determines what tools may be used to 
respond to the email. To reject this claim, the Examiner cites Marcus col. 7, lines 20-50. 
These lines relate to addressing an email message. They do not relate to responding to an 
email and certainly do not relate to determining what tools can be used to respond to an 
email message. 

Claim 27 requires that the role mode determines how much of the email message 
can be viewed by the recipient. To reject this claim, the Examiner again cites Marcus 
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col. 7, lines 20-50. Clearly these lines have nothing to do with reading an email message. 
The Examiner is reminded that an address is not a message. 

Claims 19-21 stand rejected under 35 U.S.C. § 103(a) as obvious over Marcus in 
view of Ji et al. The Examiner states that Marcus teaches all but the final clause of claim 
19 and that Ji teaches bi-directional communication between a client and a server. 
According to the Examiner, the incentive to combine the references is to "provide a 
dynamic and efficient process for using email on a network." The Examiner does not cite 
any support for the stated incentive. 

Claim 19 is drawn to an email client which has a main email component and a 
plurality of installable authoring/ reading components which communicate with the main 
email component through a bi-directional application programming interface. As 
discussed above, Marcus does not disclose a plurality of authoring/reading components 
and certainly does not suggest any "installable" components. Ji describes a method and 
apparatus for email virus detection and elimination. The Examiner cites Figs 5 A, 5B, and 
col. 7, line 58 through col. 8, line 17 of Ji for teaching or suggesting the claimed feature 
of the main email component and installable components communicating via a bi- 
directional API. Figs 5 A and 5B show a client task communicating with a server task. 
These figures are described as the preferred system for sending and receiving files. The 
cited text portion describes the operation of an FTP proxy server. Although the Ji 
reference discloses bi-directional communication, it is not through a bi-directional 
application programming interface and it is not between a main email component and an 
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installable authoring component. Thus, even if there were incentive to combine Marcus 
and Ji, it would not result in the invention claimed in claim 19. 



Dependent claim 20 describes features of the API. Neither of the cited references 
discuss an API. 

Dependent claim 21 describes features of the API. Neither of the cited references 
discuss an API. 

In light of all of the above, it is submitted that the claims are in order for 
allowance, and prompt allowance is earnestly requested. Should any issues remain 
outstanding, the Examiner is invited to call the undersigned attorney of record so that the 
case may proceed expeditiously to allowance. 



GORDON & JACOBSON, P.C. 
65 Woods End Road 
Stamford, CT 06905 
(203) 329-1160 

January 7, 2004 



Respectfully submitted, 




David P. Gordon 



Reg. No. 29,996 
Attorney for Applicant(s) 
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